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AN ELECTRONIC BILL PAYHEMT 
SYSTEM WITH MERCHAMT IDENTTPTCilTTnK 



Cross-Reference to Related appI i<^at:inn« 

This Application is related to U.S. Application 

Serial No. , filed , entitled AN 

ELECTRONIC BILL PAYMENT SYSTEM WITH ACCOUNT NUMBER 

5 SCHEMING, and U.S. Application Serial No. , 

filed , entitled AN ELECTRONIC BILL PAYMENT 

SYSTEM WITH ACCOUNT RANGING, which are filed 
simultaneously with this application. 

10 Technical Field 

The present invention relates to electronic 
commerce. More particularly, the present invention 
relates to an electronic bill payment system with 
merchant identification. 
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Background Art 

It has been common for many years for consumers to 
pay bills by way of a personal check written by the 
consumer to the order of an entity and delivered to 

5 that entity by mail or in person. With the 

proliferation of computers interconnected to computer 
networks, particularly the Internet, consumers can now 
pay bills electronically. However until recently it 
was not possible for a consumer, using a computer 

.0 terminal, to interact with a single payment system 

capable of paying all the consumer's bills whether by 
electronic means or by a paper check. Such a system 
now exists in the form of a consolidated bill payment 
system as described by Kiaht, et al, in U.S. Patent No. 

L5 5,383,113, entitled SYSTEM AND METHOD FOR 

ELECTRONICALLY PROVIDING CUSTOMER SERVICES INCLUDING 
PAYMENT OF BILLS ^ FINANCIAL ANALYSIS AND LOANS. 

Although the consolidated bill payment system 
described by Kiaht, et al. significantly advanced the 

20 state of the art, it did not focus on several problems 

which may arise in implementing a consolidated bill 
payment system capable of automatically paying consumer 
bills to merchants. One such problem is that consumers 
or data entry personal sometimes make mistakes in 
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entering payment data required by the bill payment system. 

Such a case arises when a consumer's account 
number with a merchant is incorrectly entered. The 
payment system must submit a correct account nximber to 
5 the merchant who will use this account number to 

associate the payment with the consumer. Thus, a 
technique is needed to validate the submitted 
consumer's account number. 

A data entry person may also enter payment data 

LO which incorrectly specifies the merchant's name or 

parts of the merchant's address. It has been found 
that merchant information such as the merchant name, 
address, zip code are typically mangled at the data 
entry stage. It has been further observed that errors 

L5 will often be made upon entry of the zip code. The 

merchant's name, address, and zip code is typically 
required by the payment system in order to, for 
example, retrieve merchant records from the merchant 
database. If this data is incorrect, the payment 

20 system may be unable to retrieve the correct merchant's 

record for processing a payment. Thus, a technique is 
needed to correctly identify a merchant record 
notwithstanding the submission of erroneous merchant 
data. 
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A consolidated bill payment system must also have 
the capability to properly remit payments to the same 
merchant at more than one remittance center. Commonly 
a large commercial merchant, (e.g. , shoe company, Sears) 
will have several remittance centers distributed 
geographically so that customers can submit bills to a 
center within their location. Thus, a technique is 
required to ensure that consumer payments are remitted 
to the proper one of multiple remittance centers 
associated with the same. 

Advantageously, a consolidated payment system must 
also be able to handle the different processing formats 
and requirements of numerous separate merchant 
accounting systems. For example, each merchant's 
account system may require payment information, such as 
consumer account numbers, in a format different than 
that submitted by the consumer. For example, many 
merchant accounting systems will only accept an account 
number with some portion of a consumer's last name or 
the consumer's zip code appended to the end of the 
account number presented by the customer. 

A merchant account system may even require an 
altered consumer account number which uniquely 
identifies the consumer. For example, two consumers, 
e.g., spouses, may have identical account numbers, but 
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the merchant accounting system may designate the 
account of each consumer uniquely, such as by combining 
the account number with the prospective customer's 
name. Additionally, it is not unusual for a merchant 

5 to have different account numbers for a single 

customer. For example, an account number on an invoice 
which goes out electronically may be different from an 
account number for the same customer which goes out as 
a paper transaction. 

.0 Thus, a consolidated bill payment system must be 

able to handle the various formats required by the 
merchant accounting system of each merchant. 
Accordingly, a technique is required to transform 
payment data received from the consumer into a form 

5 compatible with a merchant's accounting system. 

Objectives of the Invention 

Accordingly, it is a general object of the present 
invention to provide a bill payment system capable of 
20 receiving bill payment data on behalf of consxmers or 

corporate users via electronic means and automatically 
paying their bills to merchants. 

It is a further object of the present invention to 
provide a bill payment system capable of handling 
25 incorrectly entered bill payment data. 
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In particular, it is an object of the present 
invention to correctly identify a merchant record based 
on received information which may include erroneous 
data. 

5 It is still a further object of the present 



invention to provide a technique for furnishing payment 
information, including a payor •s account number with a 
merchant, in a format acceptable to a particular 
merchant accounting system. 



.0 



It is another object of the present invention to 
provide a technique for validating a consumer's account 



number with a merchant. 



It is another object of the present invention to 
provide a technique for ensuring payments are remitted 



5 



to the proper remittance center. 



Additional objects, advantages, novel features of 



the present invention will become apparent to those 
skilled in the art from this disclosure, including the 
following detailed description, as well as by practice 



20 



of the invention. While the invention is described 
below with reference to preferred embodiment (s) , it 



should be understood that the invention is not limited 



25 



thereto. Those of ordinary skill in the art having 
access to the teachings herein will recognize 
additional implementations, modifications, and 
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embodiments, as well as other fields of use, which are 
within the scope of the invention as disclosed and 
claimed herein and with respect to which the invention 
could be of significant utility. 



Summarv Disclosure of the Invention 

In accordance with the present invention, a 
communications network couples a payor station, working 

10 on behalf of a consumer or corporate user, and a payee, 

typically a merchant, to a programmed computer, or 
possibly a distributed system of computers, which 
processes payment requests, allowing them to 
communicate and exchange data between themselves. The 

15 communications network may be of any type facilitating 

the flow of information among the entities, such as a 
private network or the Internet. To process payment 
requests, a first station, e.g. a payor station, 
transmits payment information, including name, address 

20 data, and a payor •s account number with one of perhaps 

thousands of payees and a second station, e.g. a 
payment processing server, receives this payment 
information and account number over the network. The 
payor station initiates payment on behalf of consumers 

25 or corporate users. The second station then processes 
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the payment inforiaation to produce an eleven digit zip 
code for the payee, and access a database of payees, 
typically merchants, to locate a payee record 
corresponding to the eleven digit zip code. In a 
5 further aspect of the present invention, the second 

station transforms the payor account number into an 
altered payor account number according to alteration 
rules. In a further aspect of the present invention, 
the payee has more than one remittance center and the 
3 second station is further configured to process an 

account nximber to identify a single remittance center 
in which to direct a payment which includes the altered 
payor account number. 

The first station collects payment requests from a 
5 plurality of consumers and feeds the requests to the 

second station. Typically, the second station is 
realized as a programmed general computer having a 
storage device and a processor. The storage device is 
configured to store a database of payee records and 

20 also includes alteration rules and validation rules for 

each payee. As will be understood by those skilled in 
the art, the storage device may be configured in any 
one of many arrangements to store and manage databases, 
and could include a long term bulk storage 

25 configuration, such as one or more hard disks. 
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The alteration rules can specify a wide variety of 
formats and may be realized as templates specifying 
fields or values, or as instructions for combining 
information from different fields. Typically, an 
altered account number is formed by coiabining the 
account number with some part of payment information or 
other information related to the payee. For example, 
the altered account number may include a portion of the 
payor's name, a portion of the payor's address, or a 
portion of the payor's zip code combined with the 
account number. 

According to another aspect of the present 
invention, validation rules for the account number are 
stored, and a determination is made as to whether the 
received account number conforms with the validation 
rules. The validation rules identify the expected 
general format for any payor account number associated 
with a payee. Validation rules are preferably realized 
as templates specifying fields or values, but may take 
on other forms, and may even be algorithms. For 
example, a check digit algorithm could process the 
account number and compare the result to a check digit. 

Preferably, the general computer of the second 
station is a mainframe or mini computer or high powered 
workstation, but could be any other processing device 
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capable of executing programmed instructions. 
Additionally, the general computer could be a 
distributed computer system in which various aspects of 
the system run on different platforms. The processor of 
5 the general computer is programmed to receive payment 

information, process the payment information, excluding 
zip code information, to produce an eleven digit zip 
code for the payee, access the database to locate a 
payee record corresponding to the eleven digit zip 
0 code, and then, preferably, makes an electronic payment 

to the payee after locating the payee record. The 
processor determines the eleven digit zip code 
preferably based on payee's name, and address, or some 
part thereof. However, the eleven digit zip code may 

.5 also be determined based on other possible combinations 

of parts of the payment information, e.g. a portion of 
the payee's address. 

In a further aspect of the present invention, the 
processor verifies the account number conforms to the 

20 validation rules, and transforms the verified account 

number into an altered account number according to the 
alteration rules. 

In a further aspect of the present invention, the 
payee has a plurality of remittance centers, and the 

25 processor further processes the verified account number 
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to identify a single remittance center of the plurality 
of remittance centers to which payment should be 
remitted* 

The processor's programed instructions can be 
5 stored on a storage medium. This article of 

manufacture may be portable, a floppy disk, a hard 
disk, a CD Rom, or other storage medium. The processor 
reads the programmed instructions from the medium and 
in accordance therewith receives payment information 
.0 including a payor's account number, processes the 

payment information, excluding zip code information, to 
produce an eleven digit zip code for the payee, and 
preferably accesses the database to locate a payee 
record corresponding to the eleven digit zip code, and 
L5 then, preferably, makes an electronic payment to the 

payee after locating the payee record. In another 
aspect of the present invention, the processor may also 
verify the account number based upon validation rules 
for account numbers associated with one of a plurality 
20 of payees, and preferably transform the account number 

into an altered account number based upon alteration 
rules of the one payee, and transmit the altered 
account number to the payee. 
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Brief Description of Drawings 

FIG. 1 is a system overview of a computerized bill 
payment system in accordance with the present 
invention. 

FIG. 2 is a diagrammatical representation of the 
remittance payment processor system of Figure 1. 

FIG. 3 is a flow chart illustrating merchant 
identification in accordance with the present 
invention. 

FIG. 4 is a block diagram illustrating how 
merchant identification accesses the merchant database. 

FIG. 5 is a flow chart illustrating account 
ranging in accordance with the present invention. 

FIG. 6 is a flow chart illustrating account 
scheming in accordance with the present invention. 

Best Mode for Carrvina out the invention 

FIG.l generally depicts a bill payment system 
including consumers 8, merchants A, a batch file 
processing system 7, a remittance payment processor 
(RPP) 3, merchant banks 5, and consumer banks 6. 

A consumer, including a corporate user, (payor) is 
the individual or other entity for whom payments are 
actually made and whose account will be debited by the 
amount of the payment. The consumers 8 typically submit 
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their payments electronically to batch file processing 
system 7. The batch file processing system 7 
represents any computer or network of computers capable 
of collecting payment requests from the cons\imers 8. 

5 Consumer banks 6 either physically or 

electronically holds money on account for consumers 8. 
These accounts are debited by the amount of any 
payments made on behalf of the consumers 8. 

Merchants (payees) 4 are the persons or other 

.0 entities to whom payments are made via the bill payment 

system on behalf of consumers. Merchants may include 
department stores, the phone company, the paper boy, a 
credit card company, as well as other persons and 
entities to whom payments are made by one or more 

L5 consumers 8. Merchants have accounts with merchant 

banks 5. 

The remittance payment processor (RPP) 3, as shown 
in Figure 2, includes a memory 16 storing programmed 
instructions for carrying out the functions of the RPP, 
20 a processor 17 for executing these instructions, and a 

merchant database 18 storing information associated 
with the merchants. A batch file processing system 7 
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If 



provides payment records collected from consvimers 8 and 
transmits the batches of records to the RPP 3. 

A network 1 connects the above-stated entities 
making communications between them possible. The 
i network may be of any type capable of facilitating the 

flow of information among the various entities. It 
could, for example, be a public telecommunication 
network, the Internet, or other type of communication 
network. The network 1 may also be physically realized 
) as one or more networks. For example, in one possible 

embodiment, consumers 8 are coupled to batch file 
processing system 7 through one network and the batch 
file processing system is coupled to the remittance 
payment processor (RPP) through another separate 
5 network. 

In operation, consumers 8 make payment requests 
electronically and these payment requests are collected 
by the batch file processing system 7. The batch file 
processing system 7 then transfers the payment requests 
20 collected from consumers 8 to the RPP 3 via the network 

1. Payment information for a consumer will include 
several different types of information, such as the 
consumer account number, the merchant name, and 
address • 
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FIG. 2 illustrates an overview of the process flow 
within the bill payment system of RPP 3. RPP 3 
receives payment information from the batch file 
processing system 1 , processes that payment 

5 information, and passes the processed information to a 

component 24 which then makes payments to merchants 4. 
A payment is implemented by crediting a merchant's 
account electronically with a bank or other financial 
institution, or transferring a check or draft to the 

0 merchant. A payment implementation also includes 

sending advice to the merchant. Advice is information 
on a bill payment presented to a merchant 
electronically in a form that the merchant's system can 
use to process the bill payment transaction and update 

5 the merchant's records. One possible mode of payment 

to a merchant is electronic funds transfer through the 
Federal Reserve Automated Clearing House (ACH) Network 
26. Another electronic payment avenue is through the 
MasterCard RPS Network 30. Another remittance advice 
20 delivery mode is through Fax 22. Additionally, payment 

can also be made non-electronically to a merchant 
causing laser printer 28 to print a check 32 or a draft 
34. There is also a direct send 21 capability whereby 
the payment system sends advice to a merchant 4. 
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RPP 3 stores or processes several different record 
types necessary to the bill payment process, A 
merchant record contains all necessary information 
needed to forward a payment. This includes a merchant 

5 name, address, and zip code. A consumer record include 

a consumer name, address, zip code, and consumer 
account number. A payment record will contain 
information related to payment, including payee 
identification, consumer identification, and the dollar 

0 amount of the transaction. The merchant records are 

stored in a merchant database 18. All other records as 
well as programmed instructions which direct the 
operation of the RPP are stored in a memory 16. The 
memory 16 could also store the merchant database 18 if 

5 desired. 

After receiving payment records from the batch 
file processing system 7, the RPP periodically 
initiates a payment cycle 20 which process the records 
to generate information which will be used to credit 

20 merchant accounts and form advice for merchant systems. 

The processing flow of the billing cycle contains, in 
addition to other processes, three particularly 
important processes necessary for successful processing 
of each payment record. These processes are merchant 

25 identification 19a, account ranging 19b, and account 
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scheming 19c, typically performed in this order. In 
the first step of processing a payment record, merchant 
identification attempts to identify a merchant in the 
merchant database 18 based on information in the 

5 payment record. In the second step, the system will 

attempt to determine a remittance center of the 
merchant to which the billing information is sent. If 
a candidate remittance center is identified, the system 
enters the third stage of processing, account scheming. 

0 In account scheming, the system attempts to normalize a 

user account with a merchant according to the 
merchant's rules. If account scheming fails, the 
system will return to the account ranging process to 
attempt to identify another candidate remittance 

5 center, and from there, again into account scheming. 

Although the above described payment cycle is a 
preferable embodiment of the RPP, a payment cycle can 
include the three processes of merchant identification 

20 19a, account ranging 19b, and 19c, in any order or 

combination. In addition, these three processes may be 
performed independently, and could also be performed 
and packaged individually outside the RPP. These three 
processes will now be described in further detailed 

25 herein referring to FIGS 3-6. 
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FIG. 3 illustrates merchant identification. Using 
merchant identification, the RPP 3 is able to retrieve 
the correct merchant record from merchant database 18 
based on a consumer's payment record submitted with 
5 possibly erroneous merchant name and address 

information, e.g., street address, city, state, zip 
code. It has been observed that data entry operators 
will often make errors in the merchant's street address 
and zip code. The RPP 3 is capable of mapping the 
0 mangled merchant information supplied in the payment 

record into the proper merchant record in the merchant 
database 18 notwithstanding the errors in the merchant 
information. Merchant identification as described 
herein, can be used in any implementation where 
5 merchant information is likely to contain errors and 

must be mapped into an existing merchant record in the 
merchant database. 

RPP 3 initiates merchant identification by step 60 
which retrieves a payment record from one of the 

20 payment records previously submitted by the batch file 

processing system 7. The RPP will first attempt to 
retrieve a merchant record from the merchant database 
18 by matching the merchant id included in the payment 
record against the records of the merchant database 18. 

25 If this is successful, the processing of the payment 
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record can continue to the payment directions stage 64. 
The payment directions stage is where the RPP 
determines where to send payments. This stage includes 
account ranging discussed below which determines the 
5 remittance center to which payment gets sent. If there 

is no match, the RPP continues to step 66. At step 66, 
the RPP maps the merchant's merchant name and address, 
excluding the provided street address and zip code, 
into an eleven digit zip code. That is, the RPP 
0 produces an eleven digit zip code based on merchant 

name, city, and state in the payment information. In 
order to avail the merchant information which the 
inventors have determined to be mostly likely to 
contain errors, the received merchant street address 

L5 and zip code are not considered. Hence, in step 66 the 

RPP 3 identifies an eleven digit zip code based only on 
the merchant's name, city, and state. 

Step 66 of merchant identification uses the 
indexing structure shown in Figure 4 to access one or 

20 more records from the merchant database 18. 

In step 66, the RPP 3 forms a 11 digit zip code 
index 82 to associating;, the index entry with a merchant 
record in merchant database 18 via index 84. It may be 
possible that there is more than one merchant at a 

25 location identified by an eleven digit zip code. For 
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example^ there could be a remittance processing center 
on the floor of the building identified by the eleven 
digit zip code which handles payments for several 
merchants 4. In such a case, the RPP differentiates 
5 the correct merchant record from other possibly correct 

merchant records associated with the same eleven digit 
zip code by, after identifying merchant records indexed 
to the same eleven digit zip code, comparing some 
portion of the merchant's name, e.g., the first five 
Q characters with the characters of each merchant's name 

which has been combined with the application zip code 
in the merchant index. The RPP 3 is thereby able to 
uniquely identify the proper merchant record. 

If step 66 identifies a unique merchant record 
5 processing continues to step 64. However, if step 66 

retrieves more than one merchant forming a group of 
records 86, then at step 67 the RPP 3 will attempt to 
match one or more characters of the merchant's name 83 
against the records 86 to identify a merchant record. 

20 If a match is found, processing continues to the 

payment directions stage 64. If there is no match, 
then the RPP will handle this contingency at step 68. 
If there is no merchant, the system may have provisions 
at step 68 for adding the merchant to the merchant 

25 database 18. 
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FIG. 5 illustrates a payment direction stage, as 
performed in the preferred embodiment of the present 
invention, in which the RPP attempts to determine a 
remittance center to which payment is sent. The RPP 
5 determines a remittance center based on one or more of 

the following identification rules: l) length of 
account number, 2) merchant zip code, 3) merchant name, 
and 4) account ranging. Each rule has in common that 
it identifies the remittance center based on some 
10 factor of the payment information. 

In Figure 5, the RPP 3 processes the payment 
record presented' in step 51 to determine one of a 
plurality of remittance centers associated with the 
applicable merchant in which to make payment. In step 
53, the RPP chooses one of the above-mentioned four 
rules and at step 55 attempts to identify a remittance 
center. If a remittance center is found at step 56, 
then the RPP directs payment to that remittance center 
58. If the RPP is unsuccessful in determining a 
remittance center, the RPP cycles back to step 53 and 
picks a new rule for identification. By this process, 
the system cycles through all combinations of rules 
that identify remittance centers for the merchant. 



L5 



20 
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In account ranging^ the correct remittance center 
is determined based on some characteristic of the 
consumer's account number. Typically a large merchant, 
such as credit card company will have multiple 
5 remittance centers to which respective consumer 

payments must be submitted. The payment record 
contains information which may be used to identify a 
remittance center besides an account number, such as an 
area code of the payor's telephone number. A telephone 

LO phone utility might include each consumer's area code 

in the consumer's account number and require payments 
from all consumers within a particular area code be 
directed to a particular one of multiple remittance 
centers. A credit card company may require that 

L5 payments from all consumers having the same first six 

digits in their account numbers be made to the same 
remittance center. 

The payment direction process illustrated in 
. Figure 5 is a preferred embodiment for determining 

20 payment direction. In this embodiment, the payment 

direction process includes account ranging as one of 
four possible methods of identifying a remittance 
center. However, in other embodiments, account ranging 
may be used in different combinations, or 

25 independently. 
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FIG, 6 illustrates the steps for account scheming. 
In certain cases, the consumer account number received 
by the RPP as part of the payment information may 
contain errors. Hence, the RPP has no way of checking 

5 the account number against a previously stored account 

number associated with the applicable consumer to 
verify the accuracy of the received information. 

Using account scheming, the RPP receives, in step 
12a, the consumer account number as part of the payment 

LO record. In step 42, the RPP checks to validate the 

account number. Then in step 46, the RPP alters the 
account number to correspond to a format required by a 
merchant's system 4 for processing. 

More particularly, the RPP validates and alters 

15 the consumer account number by storing separate 

business rules for each merchant which identify the 
expected general format for any consumer account number 
associated with that merchant. These business rules 
are stored as validation templates 40 in merchant 

20 database 18 for each merchant. The account number 

received from the consumer is checked against the 
validation template to validate that the account number 
conforms to the general account number format to which 
an account number associated with the applicable 

25 merchant must conform. For example, the validation 
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template for a merchant such as a credit card company 
may require an account number begin with the numbers 
"43" and be 18 digits long. Additionally, for some 
merchants the validation template will have check digit 
5 requirements. That is, the validation template can be 

used to confirm that the received consumer account 
number conforms to a check digit after being run 
through a specific algorithm. 

In operation, the RPP 3 performs, in accordance 

.0 with programmed instructions stored on the memory 16, 

the validation procedure by comparing in step 42 the 
received consumer account number for the applicable 
merchant received in step 12a with the validation 
template, say 40, for that merchant to test the 

15 validity of the account number. If that account number 

is not valid, the payment directions are rejected as 
not valid in step 43; otherwise, the account number is 
considered valid. 

Once the account number has been validated, it is 

20 then modified in step 46 so as to conform to alteration 

rules 44 for the applicable merchant. The alteration 
rules 44 are also stored in database 18. The 
alteration rules 44 relate to the format of the 
consumer's account number in which the applicable 

25 merchant system requires to process a consumer's 
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payment. Typically, alteration rules would specify an 
altered account number which includes a portion of a 
payor's name with the account number, a portion of the 
payor's address with the account number, or a portion 
5 of the payor's zip code with the account number* 



Alteration by the RPP 3 involves notifying the received 
account number which will be furnished, along with 
payment, to the merchant. For instance, some merchant 
systems require that the consumer's account number 



10 



always end in "120". Hence, in such a case, the RPP 3, 
in accordance with programmed instructions stored on 



the memory 16, modifies the received account number to 



append "120" to the end of the alpha-numeric sequence 



of the received account number. Once the account 



15 



number has been modified so as to conform to the format 



required by the merchant system, the altered account 



niomber 47 is then transmitted from the RPP 3 to the 



merchant 4 via the network 1, along with the payment. 



in step 48. 



20 



It will also be recognized by those skilled in the 



art that, while the invention has been described above 



in terms of one or more preferred embodiments, it is 



not limited thereto. Various features and aspects of 
the above described invention may be used individually 



25 



or jointly. Further, although the invention has been 
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described in the context of its implementation in a 
particular environment and for particular purposes, 
e.g. a bill payment system, those skilled in the art 
will recognize that its usefulness is not limited 
thereto and that the present invention can be 
beneficially utilized in any number of environments and 
implementations. Accordingly, the claims set forth 
below should be construed in view of the full breadth 
and spirit of the invention as disclosed herein. 

The present invention is not to be limited in 
scope by the specific embodiments described herein. 
Indeed, various modifications of the present invention, 
in addition to those described herein, will be apparent 
to those of skill in the art from the foregoing 
description and accompanying drawings. Thus, such 
modifications are intended to fall within the scope of 
the appended claims 
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